I had Claude do a little analysis of how the engine is using the code in the system directory, and it noticed that we're not using a bunch of code! The n_per_slab = 0 line that it mentions below was added in 2011...

Draft for now pending all the big engine PR's.

AI Disclosure

Pretty much 100% Claude. 🤖

It wrote the following PR message...

Summary

Remove the stash/slab/doubling_stash object pool allocator from M2/Macaulay2/e/ and replace all call sites with direct GC allocation (newarray_clear/freemem). Also remove several pieces of dead code in the engine that referenced the system/ concurrency directory.

Net change: −552 lines across 39 files, with mem.hpp and mem.cpp deleted entirely.

Background

stash was a fixed-size object pool designed to amortize allocation overhead for hot paths in Gröbner basis and resolution computation. The design allocated memory in large slabs, chopped them into equal-sized pieces, and kept a free list for reuse.

However, the slab allocator had been silently disabled: n_per_slab was hardcoded to 0 in the stash constructor, immediately overriding the calculated value. With n_per_slab == 0:

• new_elem() reduced to return newarray_clear(char, element_size) — a plain GC allocation.
• delete_elem() reduced to freemem(p) — a plain GC free.
• The slab list, free list, and statistics fields were never touched.
• The spinlock protecting the free list was initialised and (in the destructor) acquired, but never actually guarded anything — and the destructor never released it.
• The doubling_stash global (doubles) was initialised in engine.cpp but doubles->new_elem() / doubles->delete_elem() were never called anywhere.

The stash class was therefore just a layer of indirection on top of newarray_clear/freemem with no effect on behaviour.

Changes

Dead code removed

• NCAlgebras/NCF4.cpp: removed #include of supervisorinterface.h, which was only needed for a commented-out getAllowableThreads() debug line.
• schreyer-resolution/res-f4.cpp: removed a #if 0 block containing experimental thread-task test code (testFcn1, testFcn2, testTasks) and its disabled call site in the F4Res constructor. The file already uses mtbb::parallel_for for its actual parallelism.

Stash removal

• mem.hpp / mem.cpp: removed the slab, stash, and doubling_stash class definitions and their implementations. The files contained nothing else of use and have been deleted.
• GB computation (gbring, gb-default, gb-toric, montable): stash->new_elem() → newarray_clear(T, 1) or newarray_clear(char, size) for variable-size structs; stash->delete_elem(p) → freemem(p).
• Monomial ideal / Hilbert function (monideal, hilb, schreyer-resolution/res-f4-monlookup): same substitution, plus removal of the shared-stash parameter that threaded a stash * through constructors of MonomialIdeal, monideal_pair, partition_table, and ResF4MonomialLookupTableT. The sharing was a no-op since the pool was already just calling newarray_clear/freemem. Also cleaned up the count-field ownership bit in MonomialIdeal and ResF4MonomialLookupTableT that tracked whether an instance owned its stash.
• Resolution code (res-a0, res-a1, res-a2 and their *-poly companions): same substitution. Note that res2_pair_stash in res-a0 was created but new_elem/delete_elem were never called on it.
• Remaining references (engine.cpp, debug, finalize, f4/f4-computation, f4/f4-spairs, interface/monomial-ideal): removed stash::stats() calls, the dstash() debug function, the doubles = new doubling_stash initialisation, and stale #includes.
• Build system (e/Makefile.files.in, d/Makefile.files.in, system/CMakeLists.txt): removed references to deleted files and updated a stale comment.

Possible future work

If allocation performance in the GB hot paths ever proves to be a bottleneck, the GC is not necessarily the right long-term allocator for these objects. The GC has to scan all live heap memory for pointers on every collection cycle, and its thread-safe allocation path carries overhead compared to a purpose-built pool.

However, replacing GC allocation here is not a straightforward drop-in. Many of the structs involved — gbvector, spair, Nmi_node, res_pair, and their relatives — contain ring_elem fields whose values are themselves GC-managed. Moving the containing struct off the GC heap would require either registering it as a GC root or restructuring the data so that coefficients are kept alive through some other means. Objects that are purely integer data (exponent vectors, raw monomials) have no such constraint and would be the easiest to migrate.

Two approaches are worth considering:

Arena/bump allocation per computation step. The existing f4/memblock.hpp and schreyer-resolution/res-memblock.hpp already implement this pattern: a bump allocator that is reset at the end of each degree step, with zero per-object free overhead. This is well-suited to objects whose lifetime is bounded by a single step of the GB algorithm. Extending this pattern to gbvector, spair, and similar types would be a natural next step, provided the coefficient lifetime issue is handled (e.g., by keeping a separate GC-visible list of live coefficients, or by moving to non-GC coefficient storage).

TBB scalable allocator. tbb::scalable_allocator (already a project dependency via m2tbb.hpp) uses thread-local caches and avoids the GC's collection overhead entirely. It is the better choice for objects with irregular lifetimes that do not fit a simple arena model, and would likely outperform the GC for the free-list-heavy patterns in monomial ideal tree nodes and resolution pair lists. The same caveat about GC-managed fields applies.

Either path requires profiling to confirm that allocation is actually the bottleneck before undertaking the work.

Testing

This PR makes no intentional behaviour change — every allocation that previously went through stash already went directly to the GC allocator. The standard test suite should be sufficient to confirm no regressions.